Spécification et vérification formelles des systèmes de composants répartis. (Formal specification and verification of distributed component systems)

ion→ abstraction id of id ’{’ abstraction de types TypeDecl∗ déclarations de type Field∗ variables locales Constructor∗ constructeurs abstraits Operator∗ opérateurs abstraits ’}’ Constructor→ Type ’(’ args ’)’ sign. du constructeur concret [ abstracted as Type ’(’ args ’)’ ’{’ Body ’}’ ] version abstraite Operator→ Type id ’(’ args ’)’ sign. du operateur concret [ abstracted as Type id ’(’ args ’)’ ’{’ Body ’}’ ] version abstraite Field→ Type id type & nom de la variable [ abstracted as Type ] mapping local d’un type Figure 3.6: Syntaxe pour la définition d’un type abstrait repose sur deux parties: Tout d’abord, celui qui construit le comportement de contrôle des composants. Dans cette phase, la plupart des informations qui sont nécessaires proviennent de l’analyse de la structure des composants, et du flot de futurs. Pour le dernier, nous développons des modèles comportamentaux qui nous permettent de vérifier les problèmes liés à la synchronisation de futurs. En plus, nous proposons un modèle pour la partie fonctionnelle des composants. Cela exige de faire une analyse statique sur la spécification afin de trouver le graphe d’appel de méthodes. Pour JDC, il est plus facile à faire que dans le cas de Java (non structuré) parce que pour les objets actifs nous avons des problèmes pour identifier précisément les appels de méthode distante. Le graphe d’appel de méthodes est ensuite utilisé dans le modèle de génération pour créer les réseaux de LTS. En supposant que le composant C dispose de 2 sous-composants A et B comme dans la figure 3.7, cela créera un pNet comme dans la figure 3.8. Figure 3.7: Un composant composite